<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
		<title>Because STATE is cheaper these days. But beware!</title>
	</head>
	<body>
		<a href="index.jsp">Back</a>
		<hr/>
		<p>The short version: we have only one complete JSP and every screen is
		a fragment injected inside it lazily. We will use javascript heavily and
		will have state, and will take advantage of it. We will also to organize 
		every produced javascript file by using a formal rule. We depend of 
		jQuery for data and html manipulation, and depend of DWR for RPC. Bellow
		the long version.</p>
		<p>Since we are producing apps to run on the browser, we have to use
		browser technologies on those apps. We also need to be able to work 
		under 'rough conditions', like a small div inside a portal or inside a 
		page that we can't reload. That's why we need to use javascript and XHR
		on this job.</p>
		<p>But javascript is too much flexible. If used without control, it can
		bring undesired problems to the project. In order to avoid such kind of 
		situation, the programming team need to use the following techniques:</p>
		<ol>
			<li>For each .html or .jsp file there will be none or exactly one
			Javascript file named after that document. If foo.jsp exists, then 
			foo.js also exists.</li>
			<li>Use html/javascript injection to avoid page reload. It makes the
			app modularization easier as well.</li>
			<li>No tag inside jsp/html file will call javascript. Buttons does 
			not have the "onclick" attribute, inputs doesn't have such events;
			instead all business-relevant tags will have id's so they can be
			referenced inside the related javascript.</li>
			<li>All Javascript file starts by getting the references from the 
			related .jsp file; it is made by the document.getElementById('id')
			function if no framework is available or by the $("#id") jQuery 
			selector. Then comes the secondary variables declaration, the local
			utility functions after that, events registering/implementing and 
			finally the basic screen setup. I''s much more clear by seeing the
			sample code.</li>
			<li>All javascript is data-centric. Every script will have some kind
			of principal object, which usually starts materialized as a 
			secondary variable, and no matter the current screen/script needs to
			do, the first thing to do is to assure the correct translation of 
			this object from javascript to java by sending/receiving such object
			to/from DWR callback.</li>
			<li>Whenever one script/jsp needs to pass data to another one, it 
			will inject with XHR the desired screen and left important data 
			under a well-know scope. An quotation history listing screen can 
			left the selected value under the window object so the new 
			quotation screen can use that object to fill some fields.</li>
			<li>All callbacks will receive only one bean; it means that if more
			than one transfer object is needed, another transfer object 
			containing all needed objects will be created.</li>
		</ol>
		<p>Also remember that scripts don't replace others; they increment each
		other, even if such behavior isn't planned.</p>
		<p>The best way is to take advantage of it, and always keep in mind that
		instances will be alive until page gets refreshed. Not forgetting this 
		reality is the best way to find quickly the source of tricky problems.</p>
	</body>
</html>